Isolating Bottlenecks in the Pipeline: Overview

Isolating Bottlenecks in the Pipeline: Overview

The basic strategy for isolating bottlenecks is to measure the time it takes to execute a program (or part of a program) and then change the code in ways that don't alter its performance (except by adding or subtracting work at a single point in the graphics pipeline.) If changing the amount of work at a given stage of the pipeline does not alter performance appreciably, that stage is not the bottleneck. If there is a noticeable difference in performance, you've found a bottleneck.

CPU bottlenecks. The most common bottleneck occurs when the application program does not feed the graphics subsystem fast enough. Such programs are called CPU limited.
To test for a CPU bottleneck, remove as much graphics work as possible, while preserving the behavior of the application in terms of the number of instructions executed and the way memory is accessed. Often, changing just a few OpenGL calls is a sufficient test. For example, replacing vertex and normal calls like glVertex3fv() and glNormal3fv() with color subroutine calls like glColor3fv() preserves the CPU behavior while eliminating all drawing and lighting work in the graphics pipeline. If making these changes does not significantly improve performance, then your application has a CPU bottleneck. For more information, see "CPU Tuning: Basics".
Geometry bottlenecks. Programs that create bottlenecks in the geometry (per-polygon) stage are called transform limited. To test for bottlenecks in geometry operations, change the program so that the application code runs at the same speed and the same number of pixels are filled, but the geometry work is reduced. For example, if you are using lighting, call glDisable() with a GL_LIGHTING argument to turn off lighting temporarily. If performance improves, your application has a per-polygon bottleneck. For more information, see "Tuning the Geometry Subsystem".
Rasterization bottlenecks. Programs that cause bottlenecks at the rasterization (per-pixel) stage in the pipeline are fillrate limited. To test for bottlenecks in rasterization operations, shrink objects or make the window smaller to reduce the number of active pixels. This technique won't work if your program alters its behavior based on the sizes of objects or the size of the window. You can also reduce the work done per pixel by turning off per-pixel operations such as depth-buffering, texturing, or alpha blending. If any of these experiments speeds up the program, it has a perpixel bottleneck. For more information, see "Tuning the Raster Subsystem".

In general, it is easiest to first determine if your application is host (CPU) limited using osview and checking whether the CPU usage is near 100%. Then check whether the application is fill (per-pixel) limited by shrinking the window. You then only have to prove that it's geometry limited. The osview program also includes statistics that indicate whether the performance bottleneck is in the graphics subsystem or in the host.

Many programs draw a variety of things, each of which stresses different parts of the system. Decompose such a program into pieces and time each piece. You can then focus on tuning the slowest pieces. For an example of such a process, see Chapter 13, "Tuning Graphics Applications: Examples."